Subject: Minutes of 10/11 DLSw RIG session

From: "Peter W. Gayek" <[email-masked]>
Date: Mon, 17 Oct 94 16:02:26 EDT

The following are the key decisions and discussion from the first MIB
session in last week's AIW meeting (Tuesday afternoon 10/11).  The
item numbers are taken from Dave Chen's "DLSw MIB Item List" foils.
There were about 16 people present at the session.

- Deirdre Kostick opened the meeting with some background on the DLSw
  MIB effort, and a short presentation on how to define SNMP conformance
  groups
- Dave Chen proposed the following statuses for items, and these were
  used during the session:
   OPEN -- Item identified, yet to be discussed
   WORKING -- Discussing among DLSw participants
   VOTING -- Poll for consensus
   CLOSED -- (to be) implemented in the DLSw MIB version 1
   DEFERRED -- deferred to DLSw MIB version 2
- We discussed 13 items which had been mentioned at AIW 5 and made
  decisions as listed at the bottom of this post
- We started going through a comparison of two MIBs on the
  ftp server:  draft-ibm-dlswnm-mib-00.txt and wellfleet-dlsw-mib.txt.
  The following ideas in the Wellfleet MIB were identified
  for inclusion in the next draft of the AIW DLSw MIB:
  - table to show/control what interfaces DLSw is active on
  - concept of virtual ring max MTU size
  - TCP window size

Please send any corrections or additions to this mailing list.
Peter Gayek

----------------- Work items, with decisions reached ----------------

   ITEM 1: Should the MIB allow more than one DLSw entities?
   Decision:  Only one DLSw entity per box, anyone needing more
     can use community name concepts.
   Status:  CLOSED

   ITEM 2: Should the MIB allow transport connections other than TCP/IP?
   Decision:  Definite agreement that we want to be able to support
     other transport protocols with this MIB.  Precise mechanism is
     to be agreed upon - if someone has suggestions to improve on the
     domain/address construct, please submit to the mailing list.
     Also, consensus that we should allow for transport-specific
     parameters to be defined.
   Status:  CLOSED

   ITEM 3: Align with DLC MIBs (SDLC, 802.2 LLC), NAU/APPN MIBs
     and pointers to those MIBs
   Decision:  Everyone agrees with this non-duplication position.
   Status:  CLOSED

   ITEM 4: Should the MIB be designed for configuring data link switches
   Decision:  We will have admin objects for configuring common
     parameters.  To accomodate products that don't want to allow
     SNMP-based configuring, these objects will have read-only minimum
     access defined in group conformance statements.
   Status:  CLOSED

   ITEM 5: Size of the MIB
   Discussion:  All agree we need to keep the MIB from getting "too
     big".  This will be a continuing work item as we go through
     objects and see which are needed.  Individual objects may be
     placed into conformance groups, but there were differences of
     philosophy expressed about the proper ways to use these groups
     to control MIB size.  This item is left open so we can revisit
     the issue after we've done some more detail work.
   Status: WORKING

   ITEM 6: One set of Capabilities Exchange for
     all (e.g., one set of CapEx to be sent to all partners), or
     partner dependent (e.g., one CapEx for each partner), or
     transport type dependent (eg, one for each transport type), or
     ... ?
   Decision:  For our node's capabilities, we will have only one set of
     objects.  These may change (so different values may be sent to
     each partner) but only the latest values are MIB-accessible.
     There will be no admin objects to configure our node's capabilities
     on a partner basis.
     NOTE:  further discussion on Wednesday overturned part of these
     decisions.  We will review both our capabilities and also transport
     specific parameters to identify any that should be configurable
     on a partner basis.
   Status: CLOSED (but apparently it's really WORKING)

  The following 5 items were deemed to be desirable characteristics for
  our MIB, ones we should keep in mind.  They will be combined into a
  set of guidelines to check as we are developing the MIB, and at the end.
   ITEM 7: SNMP SET and dynamic configuration operations should be
     clearly specified.
   ITEM 8: MIB should be consistent with DLSw protocol.
   ITEM 9: Implication to NMS, e.g., MIB browser. (being able to dump
     a changing table successfully)
   ITEM 10: When developing the MIB, it should always keep in mind of
     how NMS uses these objects.
   ITEM 11: What condition that traps will get generated should be
     clearly stated.

  The following 2 items seemed to be duplicates of ITEM 5, and will
  be combined with that item and left in WORKING state.
   ITEM 12: If it is vendor's option to implement some of the objects
     (e.g., counters), how to specify this situation in the
     MIB module?  In description clause?  Any precedent?
   ITEM 13: Balance between
     a minimum set of "standard" MIB with a bunch of similar
     enterprise specific objects, and
     a large "standard" MIB with a bunch of "optional" objects

  The mailing list excerpts in Dave's foils following ITEM 13 were
  not discussed apart from the items they covered.